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The International Space Station global positioning systems (GPS) receiver was activated 
in April 2002. Since that time, numerous software anomalies surfaced that had to be worked 
around. Some of the software problems required waivers, such as the time function, while 
others required extensive operator intervention, such as numerous power cycles. Eventually, 
enough anomalies surfaced that the three pieces of code included in the GPS unit have been 
re-written and the GPS units were upgraded. The technical aspects of the problems are 
discussed, as well as the underlying causes that led to the delivery of a product that has had 
so many problems. The technical aspects of the problems included physical phenomena that 
were not well understood, such as the affect that the ionosphere would have on the GPS 
measurements. The underlying causes were traced to inappropriate use of legacy software, 
changing requirements, inadequate software processes, unrealistic schedules, incorrect 
contract type, and unclear ownership responsibilities. 


I. Introduction 

Traditionally, space vehicles use ground tracking to provide position and velocity information; and star trackers, 
sun sensors. Earth sensors, and/or magnetometers to provide attitude information. Ground tracking uses ground 
based antennas to determine the orbits of spacecraft, as well as orbital debris. The U.S. segment of International 
Space Station (ISS) has been using GPS as its primary source of information for position, velocity, attitude, and time 
since April 2002 1 . The ISS GPS receiver procured by NASA is a GPS/Inertial Navigation System (GPS/INS). The 
GPS/INS architecture has been used successfully in military aircraft, tactical missile, and ground applications for the 
past 10 years. Other configurations have been used successfully on more than a dozen space missions and are the 
primary navigator on multiple launch vehicles 3 . The ISS, Crew Return Vehicle (CRV), and Shuttle GPS/INS 
developments were the first developed. 

The GPS/INS procured by NASA was intended to provide a ‘common’ navigation sensor that would fulfill the 
Space Shuttle, ISS, and CRV requirements. In theory, a common navigation sensor would provide cost savings. For 
the Shuttle, the GPS/INS was to replace the High Accuracy Inertial Navigation System (HAINS) and the 
Miniaturized Airborne GPS Receiver (MAGR). For ISS, the GPS/INS is the navigation, attitude, and time sensor for 
the U.S. segment of the ISS. For Crew Return Vehicle, the GPS/INS was to be the primary navigation and attitude 
sensor. 

Unfortunately, the goal of developing a common navigation sensor was never fully realized. Shuttle’s GPS/INS 
used a different GPS receiver than the ISS/CRV GPS/INS and required a completely different software interface due 
to the requirement to maintain transparency with the heritage Shuttle avionics system. 

ISS’s and CRV’s GPS/INS are very similar in hardware, and the software interface was intended to 
accommodate both projects. In 2001, however, the software between the two programs diverged enough that the 
throughput of one of the processor was not capable of implementing the diverse system requirements for both 
mission applications. Although the hardware for ISS and CRV was similar, the ISS program did not initially have 
any requirements for the accelerometers or gyros in the GPS/INS. However, now that the unit is operational, the ISS 
program is attempting to use the accelerometer data from the INS to provide real time feedback during re-boosts in 
the future. At the time of the delivery of the flight units, the only thing common between the GPS/INSs for all three 
programs was the inertial sensor hardware, which is still currently unused by ISS. 

Shuttle GPS/INS was cancelled after the GPS/INS phase 1 flight test and development program was completed". 
CRV GPS/INS was cancelled when the CRV project was canceled. 

The Space Shuttle still uses its two star trackers to determine attitude and align the HAINS. The GPS/INS 
procurement for Space Shuttle was not intended to replace the star tracker functionality, only the HAINS and 
MAGR. The ISS does have star tracker, sun sensor. Earth sensor, and magnetometer assets on the Russian Segment 
that provide valuable independent attitude knowledge during time periods when the GPS attitude functionality is not 
usuable. 
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This paper will focus on the ISS GPS/INS. Lessons learned from Shuttle GPS/INS and Shuttle GPS can be found 
in References 4-7. 


For ISS, the GPS position and velocity solutions from the two GPS receivers are used as updates to the ISS flight 
software’s propagated orbital state, the GPS attitude solutions are used as inputs in the ISS flight software’s attitude 
filter, and the GPS time output is used to correct the ISS on-board clocks. The GPS position, velocity, and attitude 
solutions are all unfiltered when received by the ISS flight software, which then filters the position, velocity, and 
attitude information for on-board use. Future releases of the ISS software will include a filter for time so that the 
time output can be used autonomously. 
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Figure 1 Block diagram of ISS GPS/INS. 



Figure 2 ISS GPS subsystem. 


For the ISS GPS/INS, the GPS receiver 
manufacturer provided the GPS hardware and the GPS 
navigation software. NASA provided the GPS attitude 
software that resides within the GPS receiver. The 
GPS/INS integrator provided the integrated GPS/INS, 
the INS hardware, as well as the System Processor 
(SP) software that reads in the GPS receiver data and 
formats it for output over the MIL-STD 1553B bus. 
The data from the GPS receiver navigation firmware 
are passed Othrough the GPS attitude firmware to the 
SP. The SP software also included the Kalman filter 
needed by CRV to blend the inertial and GPS 
measurements, and a GPS-only filter intended for use 
on ISS. The GPS-only Kalman filter was never used 
by ISS due to operational complexities associated with 
using it. Figure 1 shows a block diagram of ISS 
GPS/INS and Figure 2 shows the ISS and the GPS 
Antenna Assemblies (AA). 

After three years of on-orbit experience, the GPS 
continues to be used as the primary navigation, 
attitude, and time data source for ISS; however, some 
problems surfaced during operations that were not 
discovered during pre-flight simulation tests or Space 
Shuttle flight tests. As a result, the software in the GPS 
attitude code was totally rewritten using a code 
standard, and new GPS attitude algorithms were 
developed that are uniquely suited for ISS. In addition, 
the software that processes the time output from the 
GPS receiver was rewritten, while the GPS navigation 
code received minor revisions. 


The re-written code has been delivered to the ISS program and the GPS/INS units were upgraded with the new 
software in November 2004 for the first unit and February 2005 for the second unit. The new software has had 
substantially fewer problems as will be discussed later. 


Table 1 ISS Navigation Requirements 


Semi major axis accuracy 
Position accuracy 
Attitude accuracy 
Time Accuracy 


1000 feet 3 sigma 
3000 feet 3 sigma 
0.5 degrees 3 sigma 
100 microseconds 3 sigma 


The requirements for the ISS are shown in Table 1. GPS alone can meet the semi-major axis and time 
requirements. However, the multipath environment on ISS is such that the unfiltered GPS attitude solutions can not 
meet the 0.5 degree requirement. Unfiltered GPS attitude data is filtered with rate gyro data by the ISS software, 
resulting in an attitude output which does meet the 0.5 degree requirement. 
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The GPS implementation on the ISS includes four GPS antennas as seen in Figure 2. Three GPS antennas are 
required for three dimensional attitude determination calculations and one antenna is required for position, velocity, 
and time calculations. There are two GPS/INS units in the United State Lab Module, also shown in Figure 2. For 
manned space flight, the requirement is for a system to be two-fault tolerant, meaning that following two faults, the 
system still meets requirements. For the ISS implementation, the Russian Segment avionics provide the third string 
of redundancy so that if both of the U.S. GPS/INSs fail, the ISS can still navigate using the Russian assets. Prior to 
the activation of the GPS/INS units in April 2002, the ISS navigated and determined attitude safely using the 
Russian segment alone. 

Figure 3 shows a diagram of the U.S. and Russian segment navigation and attitude determination assets. 
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Figure 3 ISS GNC overview. 
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Notice that the Russian Segment has three sets of computers for fault tolerance while the U.S. side has only two. 
The Russian segment was the first deployed and had to meet the two fault tolerant requirement in the absence of any 
U.S. assets. The U.S. and Russian segments exchange information. The U.S. segment can be in control (i.e., using 
the Control Moment Gyros to maintain attitude) while using the Russian attitude information as the source of 
attitude knowledge. Likewise, the Russian segment can be using thrusters to control attitude while using the U.S. 
attitude information as the source of attitude knowledge. The Russian segment has a much wider range and 
redundancy of sensors. 

II. Other Programs or Experiments Using GPS Space Based Attitude Determination 

GPS attitude determination for spacecraft was demonstrated as feasible by RADCAL in 1995 s . GPS attitude 
determination for use in a closed loop control system was first demonstrated by the REX II spacecraft in 1996 9 ' 10 . In 
preparation for determining the appropriateness of attempting to use a new technology for attitude determination on 
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ISS, NASA expended considerable effort and resources to test GPS receivers on the Space Shuttle. STS-77 flew a 
predecessor to the GPS receiver used on ISS. The receiver was mounted in the Shuttle payload bay with 4 GPS 
antennas arranged in the same 1.5 meter by 3 meter configuration that the ISS uses 11 ' 12 ' 13 . The same GPS/INS unit 
that ISS uses was flown on STS-101 and STS-106 configured with the same software as the ISS GPS/INS units used 
when they were activated in April 2002. These two flights also had the GPS/INS mounted in the Shuttle payload bay 
with four GPS antennas arranged in a 1.5 meter by 3 meter rectangle to mimic the ISS GPS antenna 
configuration 11415 . Two additional flight tests were performed on STS-100 and STS-108 using the same GPS/INS 
hardware, but the GPS/INS was mounted in a Shuttle avionics rack and was configured to use the Shuttle’s 
Miniature Airborne GPS Receiver (MAGR) GPS antennas. The STS-100 and STS-108 flight tests were primarily 
flown to demonstrate the entry performance of the GPS/INS for use on CRV: GPS attitude determination was not 

demonstrated on these flights 1 . 

Figure 4 shows the arrangement of the four GPS antennas and 
the mounting platform for the STS-101 and STS-106 missions. 
The antennas were the same for STS-77. The GPS attitude 
solutions were compared to star tracker solutions for STS-101 
and STS-106. STS-77 did not fly a star tracker, and the Shuttle’s 
attitude solution was used for comparison for that experiment. 

In addition to the flight tests, the GPS/INS code was put 
through extensive ground testing which included four months of 
simulations. Despite this extensive testing which uncovered more 
than 200 anomalies, some problems were encountered after the 

... . „ . j . GPS units were activated on the ISS in April 2002. The next 

Figure 4 Space Shuttle payload bay , , , 1 

, n , . pmp i section describes these problems. 

arrangement for STS-101 and STS-106. 1 



III. Problems Encountered that Required Operator/Mission Control Intervention 


A. Time Outputs Were Incorrect 

Time is critical to many applications on ISS, such as solar panel pointing, and communication antenna pointing. 
After the GPS/INS had been activated by the ISS program, numerous time problems were uncovered. Fortunately, 
time problems previously uncovered during the flight tests on the Shuttle and ground testing led to the time 
requirement being waived. At activation of the GPS/INS units, the time function was not used autonomously by the 
ISS software as had been planned prior to the time waiver. Had the ISS been configured to use the time from the 
GPS/INS autonomously, the time problems uncovered could have put the ISS at risk. 

In one case, the time output from the GPS/INS would not jump back to the correct time following long periods 
of tracking fewer than four satellites. It generally took periods as long as 19 hours for the problem to surface. It was 
discovered that logic put in place in the SP to accommodate the time intervals when SP was not receiving a time 
message from the GPS receiver caused problems following long outages. The GPS receiver did not output the time 
message due to the particular implementation of the integer resolution algorithm in the GPS attitude firmware. Once 
the SP’s clock and GPS receiver’s clock had drifted apart by more than 3.5 seconds during the time message 
outages, the SP code didn’t think the time output it later received from the GPS was accurate, even though it was. 
During the time that the GPS attitude software, using an integer search technique, is searching thru the integers, all 
interrupts are disabled, which also means that no messages, including the time message, are output. The time output 
from the GPS receiver could cease for as long as 10 seconds, which the SP code perceived as time jumps. The 
problem in the SP code was a result of the SP code attempting to accommodate these perceived time jumps due to 
the loss of time message outputs from the GPS attitude firmware. 

In other instances, the GPS/INS time was observed to jump by seconds. The cause of this particular problem was 
never fully understood; however, the time code was totally re-written and the problem has not recurred. 
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Figure 5 GPS/INS time compared to ODRC time. 



In another case, the GPS/INS’s time was observed 
to jump by 1024 weeks, an entire GPS epoch. This was 
traced to code in the GPS/INS that was attempting to 
use GPS leap seconds to determine how many GPS 
rollovers had occurred. Figure 5 shows an example of 
the time data from the GPS/INS on the ISS. The 
GPS/INS’s time is compared to the time stamp placed 
on the telemetered data by the Orbital Data Reduction 
Complex (ODRC). ODRC is the computer system in 
Mission Control that stores all of the flight data. The 
time stamp it places on the data is from its own clock, 
which is synced to Universal Time Coordinated (UTC). 
Notice the jump of 1024 weeks (1 GPS epoch) near the 
beginning of the plot. 


The data file for this plot contains the following: 
ODRC Time GPS/INS Seconds 


2002_142:02:08:38.296 

2002_142:02:08:39.296 

2002_142:02:08:40.296 

2002_142:02:08:41.296 

2002_142:02:08:42.296 

2002_142:02:08:43.296 

2002_142:02:08:44.296 

2002_142:02:08:45.296 

2002_142:02:08:46.296 

2002_142:02:08:47.296 

2002_142:02:08:48.296 

2002_142:02:08:49.296 

2002_142:02:08:50.296 


706068511 

706068512 

706068513 

706068514 

706068515 

706068516 time jump 
86753317 
706068518 
706068519 
706068520 
706068521 
706068522 
706068523 


Notice the time output at 2002_142:02:08:44.296 in which the GPS/INS time jumps back in time 1024 weeks, 
but recovers on the subsequent output. 

The central clock for the U.S. segment of the ISS is the clock of the Primary Command and Control (C&C) 
computer, which is a radiation hardened Intel 386-based machine that broadcasts time to all other U.S. segment 
computers and other devices via the MIL-STD 1553B network. The clock of the C&C is not intended to be precise, 
and can have a clock drift of up to one second per day uncorrected. The C&C code was designed to be synched to 
GPS/INS and automatically track GPS time output, thus negating the need for a precision clock within the C&C 
itself. However, because the time outputs from GPS/INS have been so erratic, the C&C clock has never been 
autonomously synched to GPS/INS. 

Instead, flight controllers leave the C&C clock in local mode (where the local clock is allowed to drift and is not 
reset by the time output from GPS/INS). The drift can be coarsely metered in a positive or negative direction 
through daily manual adjustment commanded by the ground. Flight controllers compute onboard time error by 
comparing timestamps on downlink telemetry to the Mission Control Center central timing system and adjusting the 
clock metering rate daily. Using this workaround, the C&C clock is kept to within +/- 2 seconds of GPS system 
time. The error is acceptable, but is outside design specifications. 

The time problems within the SP code were corrected and the new SP code has been tested in all of the scenarios 
that caused the problems noted above and has been in use on the ISS since November 2004. Unfortunately, one new 
problem has been uncovered that will occur when there are 15 leap seconds and will manifest itself as a time jump 
of entire GPS epochs. This problem will have to be corrected prior to the leap seconds reaching 15 (in a few years). 
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Figure 6 Time error in microseconds when tracking at 
least 4 satellites. 
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Figure 7 Time error in microseconds: GPS/INS RF 
port disconnected for weekend. 


Even though the GPS/INS units have been upgraded 
with the new software that fixes the time problems, the 
ISS is still not using the GPS/INS time autonomously. 
The time data from the GPS/INS’s are being evaluated 
to ensure satisfactory software performance before 
attempting to use the time data autonomously. 

The original time design did meet the requirements 
when the GPS receiver was tracking enough satellites 
to determine position, and the requirements written so 
that time only needed to meet requirements when the 
GPS receiver was determining position. Therefore, the 
software passed the initial tests, which were designed 
strictly to test conformance to the requirements. 
Subsequent tests have been designed that test the 
GPS/INS under conditions beyond the original 
requirements that are more strenuous and therefore 
more likely to detect problems. The new time design 
has been thoughtfully crafted so that even when the 
GPS is tracking less than four satellites, time 
propagates at the rate of the error in the last output 
drift rate. Previously, the SP propagated time using its 
clock, which wasn’t nearly as accurate as the GPS 
clock. The SP clock drifts at approximately 35 
microseconds per second, while the GPS receiver’s 
clock drifts at 1 to 2 microseconds per second. Under 
the new design, the time drifts at a lower rate than the 
drift rate of the GPS oscillator since the last measured 
drift rate is compensated for. Figures 5 and 6 show the 
time error for the new GPS/INS code compared to a 
True Time GPS card during a static ground test. Figure 
6 is for a time period when the GPS/INS is tracking at 
least four satellites, and Figure 7 includes a period 
when the Radio Frequency (RF) port was disconnected 
so that GPS/INS was not tracking satellites. 


B. GPS/INS Output a Not-A-Number 

On two occasions during the same day, the GPS attitude code output an IEEE 754 Not-A-Number (0x7FFF 
OxFFFF). The Not-A-Number output caused the U.S. primary and the backup ISS Guidance, Navigation, and 
Control (GNC) computers to stop processing. Attitude control was handed off from the Control Moment Gyroscope 
(CMG)-based system on the U.S. segment to the thrusters-based system on the Russian segment, resulting in loss of 
micro-gravity and use of carefully managed propellant supplies for control. Flight controllers manually pointed the 
high-rate S-band used for core system commanding, telemetry, and voice in an intense effort to maintain 
communications with the crew, while Ku-band communications for payload data, operations plans, and video were 
lost. The entire event cost a day of on-orbit operations. 

This problem could not be worked around and the GPS/INS was left unpowered for several months to protect the 
vehicle from a recurrence of the problem. A modification was made to the GNC flight code so the U.S. GNC flight 
computer would continue to function when the Not-A-Number was received. After the ISS GNC flight code was 
modified, normal operation of the GPS/INS units was resumed. The root cause of the Not-A-Number output from 
the GPS attitude code was never determined; however, all the attitude code that could have generated it has been re- 
written. No occurrences of the Not-A-Number have been noted with the new software. 


6 


C. Numerous Power Cycles 

The attitude determination code resets itself under certain circumstances, which were not seen in ground testing, 
or in any of the Shuttle flight experiments. When a reset occurs, certain parameters are cleared from memory and 
need re -initialization. This problem was fairly easy to work around, although flight controllers had to perform many 
more power cycles of the units than was originally envisioned. 

A problem was found in the SP code where it would set a particular bit called a Subsystem Flag that is part of 
the MIL-STD 1553B protocol. This setting of this bit is intended to warn the user of the data to disregard the data in 
the message. This bit was setting every 2-3 months and the GPS/INS unit could only be recovered via a power cycle. 
The root cause of the setting of the bit was never definitively determined, although the vendor was able to determine 
a most probable cause. The code that was determined to be the most likely cause was removed. The new software in 
operation in the ISS GPS/INS units has not had a recurrence of this issue. 

Although performing numerous power cycles doesn’t appear at first glance to be of much concern, the 
GPS/INS’s were not qualified to a certain number of power cycles and it was unknown what effect, if any, the 
numerous power cycles would have on the life of the units. The numerous power cycles also increased the operator 
work load. The new software has dramatically decreased the number of power cycles from several times per week to 
once every 3-4 months. 

D. Low Position and Attitude Coverage 

The integer resolution scheme in the NASA GPS attitude code was a search method originally designed for use 
in aircraft carrier phase tracking. The method used is described in reference 16. This method requires an initial 
attitude estimate, which implies operational constraints. For many of the ISS maneuvers, it is not worth the time 
required to re-initialize the GPS receiver with an attitude estimate. Also, since the attitude input has to be an aviation 
legacy East-North-Up reference frame, the attitude update would have to be constantly updated to function properly 
when the ISS is flying in an inertial hold. Instead, for certain maneuvers, it was accepted that the GPS would not be 
outputting attitude solutions. For the inertial attitudes, the attitude estimate was input as the attitude of the ISS at one 
particular moment during the orbit. However, for the rest of the orbit, any attitudes that were output were incorrect 
since the attitude estimate was incorrect. This search method required that all interrupts be stopped during the search 
time, meaning that no position, velocity, or time messages (previously discussed) were output from the attitude code 
at these times. 
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Figure 8 Attitude error in degrees for orbit simulation 
with ISS multipath environment - new GPS attitude 
firmware. 


Figure 9 Attitude error in degrees for orbit 
simulation with ISS multipath environment - 
original GPS attitude firmware. 


Figures 8 and 9 show the attitude error during a 12 hour LVLH simulation, for the old and new attitude 
algorithm with the simulated multipath environment of the ISS. 
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Since the integer resolution scheme mentioned above was not well suited for ISS, the attitude code was 
reformulated using a new integer resolution method as part of the re-code effort. This new method simply 
accumulates measurements over a user defined interval and performs a batch solution for the attitude and the 
integers. The new method 17 assumes that the ISS is in either an inertial hold or a Local Vertical Local Horizontal 
(LVLH) hold, which are the only types of attitudes the ISS flies. 

The coverage statistics for the original and new attitude algorithm for a four day simulation in which the ISS was 
place in an inertial hold are given in Table 2. The simulation includes the blockage of the ISS structure. Coverage is 
defined as the percentage of time that a fresh attitude or position solution is output. Notice the higher position and 
attitude coverage for the new method. The increased position coverage is due to the new integer resolution algorithm 
not obstructing data from being output. 


Table 2 Coverage Statistics Comparison 

Original Method New Method 

Position 23% 48% 

Attitude 15% 31% 


Unlike the original attitude determination firmware, the new firmware does not require an initial attitude 
estimate. The new firmware has more coverage and better standard deviation statistics: 26 degrees root mean square 
for the original method and 4 degrees root mean square for the new firmware. 

E. Navigation Problems 


There were also problems encountered with the GPS navigation solution passed by the SP code to the ISS GNC 
computer. These have been traced to various root causes, but the symptom was very similar in each case. Position 
and velocity solutions slowly diverge from the true state. The ISS error checking tends to accept the diverging 
solutions as valid since the GPS receiver output slowly drifted from the true state, rather than outputting a single 

anomalous solution. Figure 10 shows an example of 
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such a drift in semi-major axis. Semi-major axis 
combines the position and velocity outputs into a 
single number. For ISS, the estimated semi-major axis, 
when compensated for 12, is a fairly constant number. 

The drifts were traced to several sources. One was 
the receiver tracking satellites thru the Earth’s 
atmosphere, which caused severe distortion of the 
pseudorange measurement. Another factor was the 
health message, which was output in a separate 
message from the navigation solution, was 
occasionally being incorrectly associated with the 
previous navigation solution rather than the current 
navigation solution. 


Figure 10 Semi-major axis for May 11, 2002. 
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F. Velocity Noise Due To Ionospheric Scintillation 


ISS SIGI MINUS SPOT VELOCITY 



256.475*6 256.47B94 256 4B242 256.iB590 256.48935 256 49283 256.49631 
2002 DAY NUMBER 



Figure 11 GPS/INS velocity noise as compared to 
ground filter. 


2002 Day 256 through 266 


1 20*W 60 “W 



longitude degree 


Figure 12 Latitude and longitude for noisy GPS/INS 
velocity output. 


Velocity noise has also been observed in ISS GPS measurements. Reference 18 contains an analysis of both ISS 
and Shuttle measurements that show this phenomenon. It appears to be related to high ionospheric activity. Figure 
11 shows the GPS/INS’s velocity noise as compared to a GPS ground filter, called the Spacecraft Position Optimal 
Tracking (SPOT) filter. 

Figure 12 shows the latitude and longitude of the GPS solution when the velocity was output with an error that 
exceeded 0.5 meters/second. These noisy outputs appeared to be clustered in similar patterns as described in 
reference 19 for ionospheric scintillation. 


G. Multipath Interference Caused by the Robotic Arm 


Early in the development of the GPS/INS, it was recognized that multipath would be a significant error source 
for the attitude determination output from the GPS 20 . Extensive resources were expended to determine the effects of 
multipath on the attitude solutions and a special 
team was formed to determine the best method of 
estimating the multipath environment at each stage 
of the ISS assembly. The team conducted a series of 
live sky tests where objects of differing size and 
shape were placed near an array of 4 GPS antennas. 

The measured errors were compared to errors 
predicted by two different computer codes 21 . The 
predictions made using a Geometric Theory of 
Diffraction code compared well enough to the 
measured results and that code was selected to be 
used to predict the ISS multipath environment. 

Figure 13 shows the comparison between predicted 
and measured differential carrier phase errors for 
the STS-77 GPS data. 



Hours 


The predicted environment was used as an input 
in the GPS simulations. The GPS simulation results 
were then used as input in a simulation to determine 
whether the ISS attitude filter could meet the 0.5 


Figure 13 Measured differential carrier phase errors 
compared to GTD predicted differential carrier phase 
errors for SV24 and antennas 1 and 2 from STS-77 data. 
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degree requirement. The results from that analysis indicated that U.S. GNC could meet the requirement. Comparison 
of the on-orbit U.S. filtered attitude solution to the Russian star tracker data indicate that the U.S. segment does meet 
the 0.5 degree under the multipath conditions that were analyzed pre-flight. However, a previously un-analyzed 
situation did cause the U.S. segment to be unable to meets its attitude performance requirements. 

Figure 14 shows the position where the SSRMS was parked from May 26 - July 22, 2004, for viewing a 
spacewalk. When the SSRMS is parked over the GPS antenna array, it causes increased multipath and blockage that 
significantly degrades the GPS/INS performance. There are fewer solutions output and the solutions that are output 
are much noisier. This is primarily an impact when ISS is flying inertial attitudes, since GPS/INS attitude coverage 
in these attitudes is already low. From on-orbit experience, the coverage has been reduced enough that the attitude 

filters within the U.S. GNC flight software could not 
remain reliably converged using the attitude data from 
GPS/INS. 

While the obvious solution appears to be to avoid 
parking the SSRMS near the GPS antenna array, it is 
often operationally impossible to do so. The 
complexity of activating and physically moving the 
SSRMS requires several hours of crew time, which is 
a carefully managed commodity. This results in the 
SSRMS often being parked over the array for weeks at 
a time. When the array is parked in the antenna’s field 
of view, flight controllers reconfigure the ISS GNC 
software to utilize attitude data from the Russian 
Segment GNC system, which is available to the U.S. 
GNC flight software as a backup to GPS. 


H. GPS/INS Impacts on Mission Control State Vector Ground Processing 

Although there were no requirements on the GPS/INS to support state vector ground processing, once GPS/INS 
was operational on ISS, the benefits of such a filter became apparent. However, although the position and velocity 
accuracy requirements for GPS/INS are sufficient to support antenna pointing for TDRS communications, they are 
not sufficient to support maneuver planning, or long-term orbital prediction and debris avoidance activities 
performed by Mission Control. A Mission Control based Kalman filter that processes the GPS data on the ground 
was developed to provide more precise orbit determination using high fidelity environment modeling. 

A serious challenge faced by filter developers was lengthy GPS/INS state vector outages during integer 
resolution for attitude determination by the GPS attitude code, which lengthened the time required for the filter to 
converge on a solution. Numerous telemetry problems also affected data quality. Extensive analysis of GPS/INS 
data and lengthy development of filter data pre-processor code was required to overcome GPS/INS and ISS 
telemetry deficiencies. 

I. Impacts of Poor State Vector Coverage Following Reboost 

ISS reboosts are performed several times a year to counter atmospheric decay and to support phasing 
requirements for Shuttle, Soyuz, and Progress vehicle rendezvous. In order to perform a reboost, attitude control of 
the vehicle is handed over from U.S. segment CMG control to Russian segment thruster control, and the Russian 
segment performs the reboost itself, normally by utilizing axial thrusters on a disposable Progress resupply vehicle 
docked to the rear port of ISS. 

Because there are currently no inertial measurement units in either the U.S. or Russian GNC systems, reboosts 
are performed with no direct measurement of acceleration. Onboard state vectors in the U.S. system are 
continuously updated through the burn by applying ground predicted accelerations and (when available) GPS state 
vectors. The accuracy of the onboard state vector after the burn must remain within 60 kilometers of truth in order to 
accurately point the ISS Ku-band communications system. 
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Experience has shown performance variability in Russian reboost burns. For example, a reboost on Februrary 1 1, 
2003, was targeted for 6.0 meters/second, but problems with the Progress propulsion system resulted in an actual 
burn that was later calculated to be 4.1 meters/second. 

At the time, both Russian and U.S. flight controllers were aware that there had been a problem with the Progress, 
but were unable to establish the exact post-burnout state vector of ISS because of the lack of sensed acceleration 
data, poor state vector coverage from the GPS due to the attitude code not outputting data since the post-burnout 
attitude was an inertial hold, and the time delay required to process ground radar data. 

The onboard state vector (which was updated with accelerations assuming a nominal predicted 6.0 meter/second 
burn) eventually achieved an error of 165 kilometers before enough GPS and tracking data had been taken to 
establish the actual orbit of the vehicle and true reboost magnitude, nearly 10 hours after burn completion. 

Following this event, flight controllers modified the reboost sequence to fly a higher GPS/INS performance 
FVFH attitude for up to an orbit following reboost to increase the likelihood of acquiring post reboost state vectors. 
Flight controllers also began using accelerometers within the ISS payload system to provide an estimate of reboost 
performance. Unfortunately, these accelerometers were originally designed to monitor microgravity performance, 
not core system GNC performance, and are not always available to flight controllers in real time. 

Additionally, modifications have been made to GPS/INS firmware and U.S. GNC flight software to incorporate 
the currently unused inertial data from the GPS/INS into the U.S. GNC system by the end of 2006. 

IV. Lessons Learned 

The factors that contributed to the delivery of a GPS receiver for use on ISS that requires extensive operator 
intervention to function and extensive re-development and re-certification are discussed. 


A. Impacts of the COTS Philosophy 

The GPS/INS was procured under the philosophy that buying a product as close as possible to the vendor’s 
commercial off-the-shelf (COTS) product would be less expensive than procuring a product that was uniquely 
developed for a particular application. The cost savings were not realized, and the COTS philosophy contributed to 
the extensive software problems. The GPS/INS hardware was similar in nature to the COTS hardware, but the 
software requirements for the space application were very unique. The existing software was developed for use in 
airborne applications, not space applications. The modifications required for space application were made without 
removing or changing the functionality of the code that was uniquely developed for the airborne application. The 
GPS attitude determination integer resolution technique developed for the airborne application required that the user 
input roll and pitch, and the software would determine heading. During the time that the software was determining 
heading, all message outputs would cease. This type of scheme makes sense for an aircraft on a runway that most 
likely has roll and pitch near zero and an unknown heading, but makes no sense for the ISS application. ISS either 
know its roll, pitch, and heading within 2 degrees or there has been some sort of malfunction. This particular integer 
resolution scheme developed for the airborne application contributed to many of the programs cited in this paper. 
One of the time problems was traced to the SP code attempting to accommodate the time outages caused by the 
integer resolution scheme. The poor state vector performance following re -boosts was traced to the lack of outputs 
from the GPS receiver caused by the integer resolution scheme continually trying to converge on a solution and 
therefore not outputting any state vector solutions. The new integer resolution scheme that was designed uniquely 
for ISS does not have these restrictions and does not lead to the problems cited. 

The problems noted with the state vector output were also traced to software designed for terrestrial applications. 
One of the causes of the state vector errors was the GPS code using measurements from satellites that were below 
the local horizon and had significant errors caused by the Earth’s atmosphere delaying the signal. In a terrestrial 
application, it is impossible for a GPS receiver to track satellites below the local horizon, but in a space application 
such as ISS, satellites as low as 24 degrees below the local horizon have been tracked. These low satellites typically 
have more error on them than signals from satellites at higher elevations. After the code modification was made so 
that the GPS/INS wouldn’t track satellites lower than 10 degree below the local horizontal, the large state vectors 
errors have not recurred. 
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The COTS philosophy also dictated that NASA have limited insight into the vendor’s software since the 
development of the COTS software was not paid for by NASA and is considered proprietary. Even the software 
developed by NASA could not be obtained by the procuring NASA organization until after the development was 
complete. To mitigate the risk associated with having limited insight into the software, NASA chose to test 
extensively. The extensive testing did uncover many anomalies pre-flight, but many were only uncovered after the 
units were activated on ISS. The extensive testing could not fix the inherent design flaws in the time design or the 
attitude algorithms developed for airborne applications. 


B. Requirements Changes 

Requirements for the GPS/INS common navigator were not well defined at the start of the program, most 
notably the CRV requirements. As new system requirements were determined the changes resulted in new software 
requirements during the development. Even after the GPS/INS was operational on the ISS new ways of utilizing the 
data from the GPS/INS were being defined such as attempting to use the inertial sensor data for re-boost application. 
Ideally, all requirements would be known completely at the time of procurement. Realistically, this is rarely the 
case. The contract type should be designed to readily accommodate requirements changes. 


C. Firm, Fixed Price Contract Was Not Appropriate for This Procurement 

Relatively early in the development it was realized that the vendor was not going to be able to deliver the 
GPS/INS product for their firm, fixed price bid. Unforeseen requirement changes arose, which inevitably led to 
schedule and software development problems. In retrospect, this is easy to understand: an attitude determination 
GPS receiver integrated with an INS product had never been demonstrated in a space environment; therefore, its 
final development faced a significant degree of uncertainty and risk. The COTS hardware resulted in minimal 
impact but the software customized for space caused most of the uncertainty. Additionally, the extent of the 
modifications required to make the COTS product perform in the space environment were not clearly understood by 
the vendor when the firm, fixed price bid was made. Consequently, using a firm, fixed price contracting mechanism 
resulted in an inflexible contracting situation when technical problems and other unforeseen difficulties arose. 


D. Inadequate Software Quality Processes 

Purchasing COTS product when the vendor (which includes NASA in this case since NASA was a vendor as 
well as the customer) and NASA do not have adequate hardware and software processes in place can lead to 
significant operational problems. Both the vendor for the integrated product and the GPS receiver manufacturer had 
processes in place to ensure the quality of their hardware, and, as a result, the GPS/INS hardware has not had any 
problems. The navigation code was developed using a recognized coding standard to ensure the quality of the code. 
The SP code was developed using the vendor’s internal code standards for Department Of Defense applications 
during the ISS/CRV GPS/INS development, and NASA did not follow any code standards during the original 
development of the attitude determination software. 

The navigation code has had relatively few problems compared to the SP code and the attitude determination 
code. When the SP code was re-written, large portions of unused code were removed. When the attitude code was 
re-written, it was re-written using a code standard. The number of anomalies recorded for upgraded software is less 
than twelve. The number of anomalies recorded for the original firmware is greater than 200. 


E. Unrealistic Schedules 

The original philosophy behind COTS procurements was that the development costs had already been absorbed 
and the item’s adaptation for use in space would be both faster and cheaper. Unfortunately, in the case of the space 
software development, this was not quite true and it led to very optimistic project schedules. 

Ultimately, unrealistically optimistic schedules only lead to poor quality software that will probably still be 
delivered late. The original ISS/CRV GPS/INS development schedule allowed six months for the delivery of the 
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development units. The hardware arrived about one month late, but the software was not completed for another two 
years, after which it was tested, flown, and then extensively re-written due to its flaws. 

Although some suspected the project schedules might be optimistic, there were two reasons to think the 
schedules could have been met: 1) GPS attitude determination had been demonstrated on flight experiments and 2) 
the GPS/INS was as close to the vendor’s COTS product as possible (the hardware changes were accomplished with 
minimal effort and few problems). However, it requires a significant amount of time and effort to take software 
technology from flight experiment demonstration to the robustness required for a manned spacecraft. Additionally, 
even though a product appears to work for an existing application doesn’t mean it is free of errors or will work well 
in a different environment. 

The unrealistic schedule impacted the quality of the software product because rather than create a realistic 
schedule that included time for testing of the custom software, time to put in place coding standards, and time to 
create a well-planned software design; the vendors worked long hours until they ultimately produced a system that 
functioned, if only marginally. Additionally, the requirements were changing during the scheduled development 
cycles. 


F. Ownership 

When dealing with multi-component boxes that must be integrated into a complex system, the ownership and 
responsibility for each component must be established early on. The integration of the software and hardware 
elements should be tested and verified to firm requirements at the unit level. The flow of the requirements to each 
developmental item must be established and defined in early stages of the program. Decisions about the system 
architecture should be made by the organization responsible for the final performance. The performance must be 
measured to unmoving requirements. 

Many of the problems noted here in the development of the ISS GPS/INS are similar in nature and cause to the 
software induced spacecraft accidents discussed in reference 22, including unrealistic schedules and poor software 
processes. 


V. Conclusion 

Implementing GPS on ISS required that many technical and contractual hurdles be overcome. The technical 
problems included software anomalies as well as physical phenomena that were not well understood, along with the 
often conflicting requirements that emerge with development of a device for multiple users. The software anomalies 
were traced to inappropriate use of COTS software, inadequate requirements, and changing system requirements 
during short development cycles. The contracting problems included an inappropriate contract type and unrealistic 
schedules. 
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